Method, System and Apparatus for Matching Sellers to a Buyer Over a Network and for Managing Related Information

ABSTRACT

An improved system and method for facilitating a transaction between a buyer and one of a number of sellers is provided. The transaction is related to a project specified by the buyer. A set of sellers are identified from a database. A flow control process operates over a number of processing cycles. In each processing cycle, the flow control process selects sellers from the set for classification as sellers of a particular type (“Invited Sellers”). The system automatically enables at least one action carried out by the sellers of the particular type. The duration of the processing cycles preferably varies over the processing cycles and is derived from a time period specified by the buyer as well as a predetermined constant that results in exponential reduction of the process cycle durations. The number of sellers selected for classification as sellers of a particular type preferably varies over processing cycles and depends upon a number of offers that are submitted by sellers of the particular type and received by the buyer. In the initial processing cycle, the number of sellers selected for classification as sellers of a particular type depends on a number of offers the buyer wishes to receive as dictated by input from the buyer. In the preferred embodiment, the at least one action enabled by the process includes: i) the sellers of the particular type submitting offers and information related to the offers and storing the offers and related information (such as multimedia files) in a database for access by the buyer; ii) the sellers of the particular type accessing detailed information related to the offer; iii) communication between the sellers of the particular type and the buyer; iv) automatic notification to the sellers of the particular type of their classification to the particular type; and/or v) automatic notification to the buyer of the sellers of the particular type.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims benefits from U.S. Provisional PatentApplication No. 60/832,042, filed Jul. 20, 2006, the contents of whichare hereby incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates broadly to methods, systems and apparatus forfacilitating electronic commerce. More particularly, this inventionrelates to methods, systems and apparatus for matching buyers andsellers of goods and services.

2. State of the Art

Electronic commerce systems (such as online marketplaces, online auctionhouses, online reverse auction houses) provide a mechanism for matchingsellers with buyers for facilitating transactions related to goods andservices. For reverse auctions, there can be a significant number ofpotential sellers that can meet the demands of a respective buyer. Thisunbalance can have negative effects such as:

too much competition among sellers;

an overflow of offers submitted from sellers to a respective buyer and alow conversion ratio of acceptance of such offers by buyers;

a reduced quality of offers submitted from sellers to a respectivebuyer; and

a perception by the sellers who submit offers that the lowest pricedoffer will be accepted by the buyer.

Electronic commerce systems proposed in the prior art (for example, thesystem described in U.S. Pat. No. 6,647,373 to Carlton-Foss) facilitatereverse auctions for goods and/or services, yet fail to address theproblems that arise from the unbalance as set forth above, where thereare a significant number of potential sellers that can meet the demandsof a respective buyer, and where there are other factors apart fromprice (such as quality of the service or product offered by the seller,reputation of the seller, etc.) that may affect the decision of thebuyer. In such situations, the buyer can receive an overwhelming numberof offers, which makes it difficult and time-consuming to identify themost appropriate seller. It also makes it unpractical for sellers asthey have to compete with a large number of other sellers, whichsignificantly reduces the conversion ratio of accepted offers bysellers. Such reduced conversion ratios can negatively impact thereverse auction process as sellers spend time and effort preparing andsubmitting offers that are rejected by buyers, which can deflate themoral of the sellers and lower the quality of the offers submitted bysellers to buyers as part of the process.

Several commercially-available online systems (such as elance.com andguru.com) have attempted to address these issues by limiting the numberof offers sellers can make based on a tier system and/or by terminatingthe offer submission process when a certain number of offers have beensubmitted to the buyer. These systems are limited in their benefit to abuyer because the matching process favors sellers that submit offersquickly and does not attempt to aid the buyer in receiving better suitedoffers for the desired goods and/or services.

Thus, there remains a need in the art for improved methods, systems andapparatus for facilitating electronic commerce involving matching buyersand sellers of good and services, and particularly where such matchingis part of a reverse auction process.

SUMMARY OF THE INVENTION

It is therefore an object of the invention to provide improved methods,systems and apparatus for facilitating electronic commerce involvingmatching buyers and sellers of good and services.

It is another object of the invention to provide such methods, systemsand apparatus where matching of buyers and sellers is part of a reverseauction process.

It is a further object of the invention to provide such matching processthat is effective when there are a significant number of potentialsellers that can meet the demands of a respective buyer.

It is also an object of the invention to provide such matching processthat is effective when there are other factors apart from price (such asquality of the service or product offered by the seller, reputation ofthe seller, etc.) that may affect the decision of the buyer.

In accord with these objects, which will be discussed in detail below,an improved system and method for facilitating a transaction between abuyer and one of a number of sellers is provided. The transaction isrelated to a project specified by the buyer. A set of sellers areidentified from a database. A flow control process operates over anumber of processing cycles. In each processing cycle, the flow controlprocess selects sellers from the set for classification as sellers of aparticular type (“Invited Sellers”). The system automatically enables atleast one action carried out by the sellers of the particular type.

In the illustrative embodiment, the duration of the processing cyclesvaries over the processing cycles and is derived from a time periodspecified by the buyer as well as a predetermined constant that resultsin exponential reduction of the process cycle durations. The number ofsellers selected for classification as sellers of a particular type alsovaries over processing cycles and depends upon a number of offers thatare submitted by sellers of the particular type and received by thebuyer. In the initial processing cycle, the number of sellers selectedfor classification as sellers of a particular type depends on a numberof offers the buyer wishes to receive as dictated by input from thebuyer.

In a preferred embodiment, the at least one action enabled by theprocess includes: i) the sellers of the particular type submittingoffers and information related to the offers and storing the offers andrelated information (such as multimedia files) in a database for accessby the buyer; ii) the sellers of the particular type accessing detailedinformation related to the offer; iii) communication between the sellersof the particular type and the buyer; iv) automatic notification to thesellers of the particular type of their classification to the particulartype; and/or v) automatic notification to the buyer of the sellers ofthe particular type.

In the preferred embodiment, the selection of the sellers of the set iscarried out by calculating likelihood indices for the sellers of theset, and ranking the sellers of the set according to the correspondinglikelihood indices. This allows the selection process to select higherranked sellers before lower ranked sellers. The likelihood index for aseller are preferably derived from a number of index calculations, mostpreferably including a group of relevancy subindices and a group ofpriority subindices. The sellers of the set are preferably identified byan automated process that matches requirements of the project asspecified by the buyer to profile data of sellers.

Additional objects and advantages of the invention will become apparentto those skilled in the art upon reference to the detailed descriptiontaken in conjunction with the provided figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an electronic commerce system that includesfunctionality for matching buyers and sellers of good and services inaccordance with the present invention.

FIG. 2 is a flow chart illustrating the operations of the matchingfunctionality of the electronic commerce system of FIG. 1 in accordancewith the present invention.

FIG. 3 is a schematic illustration of an index schema that can be usedin the operations of FIG. 2 for determining a likelihood (orprobability) that an offer from a Seller will best match a Buyer'sproject in accordance with the present invention.

FIGS. 4A and 4B, collectively, is a flow chart illustrating the flowcontrol process of FIG. 2 for classifying Invited Sellers over a numberof processing cycles for a project in accordance with the presentinvention.

FIG. 4C is a graph depicting the number of Invited Sellers classifiedover each one of a number of processing cycles as part of the flowcontrol process of FIGS. 4A and 4B for an exemplary project.

FIGS. 5A1, 5A2, 5B, 5C, 5D1 and 5D2 illustrate an exemplary userinterface generated by the system of FIG. 1 for creating and managingprojects and perform related tasks where voice over talent or producersprovide voiceovers to buyers for commercial needs.

FIGS. 6A, 6B1, 6B2, 6C1 and 6C2 illustrate an exemplary user interfacegenerated by the system of FIG. 1 that allows voice over talent andproduces (a Seller) to submit and manage offer(s) and perform relatedtasks for Buyers' project(s) that are matched to the Seller by thesystem.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

For purposes of description herein, a “reverse auction” is a processwhereby a number of sellers compete for the right to provide goods orservices to a buyer. The reverse auction is different from an “ordinaryauction,” which is process whereby a number of buyers compete for theright to obtain goods or services from a seller.

Turning now to FIG. 1, there is shown the architecture of an electroniccommerce system that facilitates reverse auctions. There are two classes(denoted “Buyers” and “Sellers”) of users of the system. One or moreBuyers access the system over a network (such as the Internet) to createand manage projects. A project is a solicitation for goods and/orservices that are desired by the Buyer. Sellers of the system competefor the right to provide goods or services to a Buyer as dictated by acorresponding project. In the illustrative embodiment, a projectinvolves a number of requirements, such as one or more dates related tothe project (e.g., a start date and/or an end date) and specific needsor functions to be provided by the Seller to the Buyer. Sellers accessthe system over the network to create and maintain a profile stored onthe system. The system includes software logic that automaticallymatches a number of Sellers to a given Buyer's project that is posted orotherwise designated by the given Buyer. The system also provides forcreation, submission and management of offers related to a given Buyer'sproject by Sellers that are matched to the given Buyer's project. ASeller is matched to a given Buyer's project by classifying the Selleras an Invited Seller for this project as described below in more detail.The system also provides for communication and management of such offersbetween Buyers and Sellers in order to facilitate transactionstherebetween.

As shown in FIG. 1, a Buyer utilizes a web browser executing on acomputing device 3 to connect to a web server 5 over the network 7(e.g., Internet). Similarly, a number of Sellers each utilize a webbrowser executing on a computing device 9 to connect to the web server 5over the network 7. Preferably, the browser-based interaction betweenthe computing devices 3, 5 and the web server 5 occur over TCP/IPsessions established therebetween over which are communicated HTML-based(and possibly XML-based) documents and commands as well as othermessages, commands and data. The web server 5 enables login andauthentication of the Buyer via interaction with the Buyer system 3 aswell as login and authentication of a respective Seller via interactionwith the Seller system 9. Such login and authentication can utilizepassword-based authentication, operating system-based authentication(e.g., NTLM or Kerberos); services-based authentication (e.g., MicrosoftPassport authentication), certificate-based authentication, or any otherauthentication scheme. Once a user session has been authorized (whetherit be a Buyer session or Seller session), the web server 5 communicateswith an Application Server 11 to build dynamic web page(s) based on datasupplied by the Application Server 11 and serve the dynamic web page(s)to the Buyer web browser (or the Seller web browser) as requested, andforward (and/or transform) data supplied by the Buyer web browser (orthe Seller web browser) to the Application Server 11 as needed.Preferably, the web server 5 is located in a “demilitarized zone” (DMZ)provided with a firewall router 13. In this configuration, thefirewall/router 13 enables authorized communication between the webserver 5 and the Application Server 11 (typically utilizing a securesocket layer (SSL) interface or an IPSec interface), while blockingunauthorized communication requests to the Application Server 11. Inaddition, the web server 5 preferably utilizes style sheets to build theHTML documents (and XML documents) for presentment to the Buyer webbrowser (or to the Seller web browse). The web server 5 may be realizedby commercially available HTTP servers, such as the Apache Web Server,Microsoft Internet Information Server, and Sun ONE Web Server.

The Application Server 11 includes a Buyer Application Component 15, aSeller Application Component 17, Buyer Seller Matching Logic 16,Administration/Configuration Logic 19, a Database 21 storing buyer dataand seller data, Presentation Services 23, Network Security Services 25,and Messaging Logic/Services 27. The Administration/Configuration Logic19 provides for system management and configuration of the ApplicationServer 11. The Presentation Services 23 are facilities that enabledelivering dynamic content to client browsers. Preferably, thePresentation Services 23 support Active Server Pages, JavaServer pages,server-side scripting such as Perl, CGI, PL/SQL scripting, etc. TheNetwork Security Services 25 provides facilities that enable maintainingnetwork security (such as SSL-based or IPSec-based encryption andauthentication facilities). Preferably, the Application Server 11 isrealized by a commercially-available software framework, such as theWebLogic Platform commercially available from BEA Systems of San Jose,Calif., the Websphere Application Server commercially available fromIBM, Windows Server Systems commercially available from MicrosoftCorporation of Redmond, Wash., or the SUN ONE Application Servercommercially available from Sun Microsystems of Santa Clara, Calif.

The Database 21 maintains buyer data that pertains to a respective Buyerand to the projects of the respective Buyer as well as seller data thatpertains to a respective Seller and to the offers of the respectiveSeller. In the illustrative embodiment shown, the buyer data pertainingto a respective Buyer can include data defining open projects, projecthistory, profile of the respective Buyer, a preferred seller list,contact information for the respective Buyer, etc. The seller datapertaining to a respective Seller can include defining offers to whichthe respective seller has been matched (i.e., offers for which theSeller is classified as an Invited Seller), information related to suchoffers, offer/project history, profile of the respective Seller, contactinformation for the respective Seller, etc.

The Buyer Application component 15, works in conjunction with thePresentation Services 23 and other components of the Application Server11, to provide dynamic content to the web server 5 for delivery to thebrowser-based Buyer system 3. The Buyer Application component 15 alsoencodes logic that allows for the respective Buyer to create and manageprojects and store information pertaining thereto in the Database 21,which preferably includes access to and/or presentation of offerssubmitted by Invited Sellers for the projects of the respective Buyer aswell as information provided by the Seller related thereto.

FIGS. 5A1, 5A2, 5B, 5C, 5D1 and 5D2 depict an exemplary user interfacegenerated by the Buyer Application component 15 for creating andmanaging projects where voice over talent or producers providevoiceovers to buyers for commercial needs. The user interface iscommunicated to and rendered by the buyer system 3 by operation of a webbrowser executing on the buyer system 3.

FIGS. 5A1 and 5A2, collectively, illustrate a user interface generatedby the Buyer Application component 15 for creating a project, includinga text box 501 for assigning a name to the project, buttons 503, 505 forselectively activating and deactivating the Buyer Seller Matching logic16 described below for the project, a widget 507 for specifying thenumber of offers that the Buyer would like to receive for the project, apull down box 509 to enable the Buyer to specify the purpose of theproject, buttons 511A, 511B that allows the Buyer to specify apreference for a female or male voice, a pull down menu 513 that allowsthe Buyer to specify the language fluency requirements for the project,a set of buttons 515 that allows the Buyer to specify the voice age forthe project, a set of buttons 517 that allows the Buyer to specify theaudio recording format and delivery mechanism for the project, a set ofbuttons 519 that allows the Buyer to specify any union requirements forthe project, buttons 521 that allow the Buyer to selectively hide thename of the Buyer's company to sellers for the project, buttons 523 thatallow the Buyer to selectively attach files for the project, a textinput box 525 that allows the Buyer to provide a description of theproject, a text input box 527 that allows the Buyer to provide a scriptfor an audition for the project, a set of buttons 529 and an input box531 that allows the Buyer to describe the budget for the project, adate/time input widget 533 that allows the Buyer to define a date andtime deadline for the project, and a button 535 that is selected by theBuyer to commit storage of the project data as defined by the user inputin the Database 21 of the system.

FIG. 5B illustrates a user interface generated by the Buyer Applicationcomponent 15 for managing a project, including a selector box 541 thatenables the Buyer to navigate to a user interface (not shown) forincreasing the number of offers that the Buyer wishes to receive for aproject, a display field 543 that provides the Buyer with instructionson how to invite sellers that are not part of the system to access theproject on the system (preferably, such sellers access the project by aURL and access code that is specified in the display field 543), aselector box 545 that enables the Buyer to navigate to a user interface(not shown) for searching for sellers of the system as maintained in theDatabase 21 and for inviting selected sellers to submit an offer for theproject, and a selector box 547 that enables the Buyer to navigate to auser interface (not shown) for inviting sellers that are on the Buyer'sPreferred Seller List (as maintained in the Database 21) to submit anoffer for the project.

FIGS. 5D1 and 5D2, collectively, illustrate a user interface generatedby the Buyer Application component 15 for managing a project, includingselector box 551 that enables the Buyer to navigate to a user interface(not shown) for increasing the number of offers that the Buyer wishes toreceive for a project, a selector box 553 that enables the Buyer tonavigate to a user interface (not shown) for updating the deadline of(or reopening) the project, a selector box 555 that enables the Buyer tonavigate to a user interface (not shown) for extending audio storagetime for the project, a tabbed folder including a project detail tab557, an inbox tab 559 that provides the Buyer with access to the offerssubmitted by Invited Sellers (including the display of statusinformation related to the offers and performing various actions relatedthereto as shown), and a deleted tab 561 that provides the Buyer withaccess to offers deleted by the Buyer.

The Buyer Seller Matching Logic 16 works in conjunction with the othercomponents of the Application Server 11 to match a number of Sellers toa given Buyer's project that is posted or otherwise designated by thegiven Buyer. A Seller is matched to a given Buyer's project byclassifying the Seller as an Invited Seller for this project asdescribed below in more detail.

The Seller Application component 17, works in conjunction with thePresentation Services 23 and other components of the Application Server11, to provide dynamic content to the web server 5 for delivery to thebrowser-based Seller system 9. The Seller Application component 17 alsoencodes logic that allows Sellers to create and maintain profiles (shortdescription of goods or services, training, additional skills,experience, description of goods or services, historical price data forprojects, desired buyer preferences, project matching filter data,etc.), which are stored in the Database 21. The Seller Applicationcomponent 17 also enables the Seller to perform various actions withregard to project(s) that are matched to the Seller (such as creation,submission and management of offers related to a given Buyer's project).

FIGS. 6A, 6B1, 6B2, 6C1, and 6C2 depict an exemplary user interfacegenerated by the Seller Application component 17 that allows voice overtalent or producers (Voice Over Seller) to perform various actions withregard to project(s) that are matched to the Voice Over Seller by theMatching Logic 16. The user interface is communicated to and rendered bythe seller system 9 by operation of a web browser executing on theseller system 9. The Database 21 maintains a profile for each Voice OverSeller, which specifies one or more of the following: i) one or morelanguages that the Voice Over Seller is fluent in, ii) types of projectsthat the Voice Over Seller is interested in pursing, iii) one or morevoice ages that can be provided by the Voice Over Seller, iv) audioformat and delivery options provided by the Voice Over Seller, v) one ormore union affiliations of the Voice Over Seller, v) a description ofthe Voice Over Seller's voice, vi) a description of the experience ofthe Voice Over Seller, vii) training of the Voice Over Seller, viii)additional skills of the Voice Over Seller, ix) contact information forthe Voice Over Seller, x) means for initiating payment to the Voice OverSeller, xi) one or more audio files for demonstrating the voice overskills of the Voice Over Seller, xii) historical price data forprojects, xiii) desired buyer preferences, and xiv) project matchingfilter data.

FIG. 6A illustrates a user interface generated by the Seller Applicationcomponent 17 for notifying a Voice Over Seller that the Voice OverSeller has been matched to a Buyer's project by the Buyer SellerMatching Logic 16 as described herein. The notification is automaticallygenerated by the system and triggered by the classification of the VoiceOver Seller as an Invited Seller as described herein.

FIGS. 6B1 and 6B2, collectively, illustrate a user interface generatedby the Seller Application component 17 that allows the Voice Over Sellerto view the details of a project that the Voice Over Seller has beenmatched to. The project details include a description of the project,the date the project was posted, the deadline for the project, projectstatus (opened and receiving offers or closed), how many offersreceived, geographical requirements for the project, budget information,language requirements for the project, voice gender for the project,voice age for the project, audio recording and delivery requirements forthe project, union requirements for the project, script information forthe project, voice seeker (Buyer) details for the project, etc.

FIGS. 6C1 and 6C2, collectively, illustrate a user interface generatedby the Seller Application component 17 that allows the Voice Over Sellerto create and submit an offer for a project that the Voice Over Sellerhas been matched to. The interface enables the Voice Over Seller toupload an audio file as part of the offer (e.g., for an audition orother demonstration purposes), specify the price of the project, andprovide other relevant information as shown. The interface also includesa button that allows the Voice Over Seller to request notification ifand when the Buyer of the project opens the offer and/or informationrelated thereto as shown. The interface also provides detailedinformation regarding the project as shown. This interface is presentedto the Voice Over Seller for a given Project only in the case where theVoice Over Seller is classified as an Invited Seller for the givenproject as described herein.

The Buyer and Seller Application components 15, 17 also includefunctionality (e.g., a messaging interface) that provides forcommunication between Buyers and Sellers in order to facilitatetransactions therebetween. Messaging logic/services 27 provided by theApplication Server 11 can be used to carry out such communication. TheMessaging logic/services 27 can support voicemail for voice messages,email messaging, IM messaging, SMS messaging or other suitablecommunication services between Buyers and Sellers. FIG. 5C illustrates auser interface generated by the Buyer Application component 15 thatallows a Buyer to communicate an invitation to submit an offer for aproject. Similar interfaces can be used for other communication from theBuyer to a Seller and from a Seller to a Buyer in order to facilitatematching a Seller to a Buyer, for collaboration therebetween onprojects, for arranging payment between the Buyer and Seller, etc.

Turning now to FIG. 2, there is shown a high-level schematicrepresentation of the functions provided by the Buyer Seller MatchingLogic 16. Such functions begin in block 200 upon a Buyer creating andposting a project (P) on the system. At block 202, a selection processis carried out in which a number of sellers are selected from theDatabase 21 (block 204) based on the Sellers profiles stored therein asmatched against the requirements of the project (P) as stored therein.These Sellers are classified as “Identified Sellers.” The selectionprocess of block 204 can be rigid in nature (e.g., requiring that theSeller's profiles match all of the requirements of the project) or canbe more flexible in nature based on similarity between the Sellersprofiles and the requirements of the project (P). A weighted-treesimilarity algorithm or other suitable matching algorithm can be usedfor the similarity-based matching.

At block 206, a likelihood index table (LIT) is built for the IdentifiedSellers selected in block 202. The LIT includes a likelihood index (LI)for each Identified Seller. The LI represents the likelihood (orprobability) that an offer from the Identified Seller will best matchthe Buyer's project (P). It can also account for the level of activityof Sellers in the marketplace (in order to first invite more or lessactive Sellers) and/or account for other factors that the marketplacemay consider (in order to increase or decrease the level ofparticipation of individual Sellers). The LI for an Identified Sellercan be calculated using numerous factors, each of which is accorded adifferent weight based on an individual buyer's needs. Different marketswill likely require different factors to use in the calculation, and aBuyer can assign relative weights to the factors if desired. In anillustrative embodiment, the LI for an Identified Seller is derived fromrelevancy and priority indices as described below in more detail (FIG.3). The Identified Seller with the highest LI is predicted to have thegreatest chance of being matched to the Buyer for the project (P). TheLIT ranks the Identified Sellers by their LIs from highest LI to lowestLI. In other words, the Identified Seller(s) having the highest LI areranked first in the LIT and the Identified Seller(s) with the lowest LIare ranked last in the LIT.

At block 208, a flow control process (FCP) is carried out to regulatethe process and flow by which the Buyer receives offers from IdentifiedSellers for the project (P). The FCP is intended to increase the Buyer'schances of finding the best matching Identified Seller for the project(P) at the beginning of the process. The FCP classifies IdentifiedSellers in the LIT as “Invited Sellers” over a number of processingcycles. In each processing cycle, the FCP calculates a new number ofIdentified Sellers to classify as “invited.” The number of InvitedSellers classified and the time period calculated for each processingcycle is strategically determined in order to make the most efficientuse of the Buyer's time in finding a Seller for the project. The processby which these parameters are calculated during each processing cycle isfurther discussed below, and illustrated by FIGS. 4A and 4B.

At block 210, the system automatically performs various system tasksrelated to the project, and enables actions and/or tasks to be performedby the Invited Sellers and/or the Buyer of the project (P). Thesetasks/actions include, but are not limited to, notifying the InvitedSeller that he or she has been selected to submit one or more offers tothe Buyer; notifying the Buyer of the Invited Seller; allowingcommunication between the Invited Seller and Buyer; allowing the InvitedSeller to submit an offer to the Buyer; and additional informationexchanges.

At block 211, the process determines if the project should be closed.Projects can be closed for several reasons. For example, the project canclose automatically upon expiration of the last processing cycle of theflow control process of block 208. In another example, the Buyer candesignate a number of offers that the Buyer wants to receive during theprocess. The system can track the number of offers that the Buyerreceives during the process and close the process when the trackednumber of received offers matches the number of wanted offers designatedby the Buyer. In other examples, the project can be closed when thedeadline for receiving offers has passed; the Buyer has already selecteda Seller; the Buyer opted to stop receiving offers before the originaldeadline; etc. If closed, the project could be reopened at any time uponthe Buyer's request, thus restarting or reactivating the process.

At block 212, the system determines whether the project (P) has beenclosed. If the project (P) has not yet closed, the system returns toblock 208 to continue the FCP process. If the project has closed, thesystem can automatically perform various system tasks related to theproject before it ends. Such system tasks can include:

(1) notification to Invited Seller(s) that the project has closed (whichcan be accomplished by the mechanisms discussed above);

(2) notification to the Buyer that the project has closed (which can beaccomplished by the mechanisms discussed above);

(3) disabling communication between the Invited Seller(s) and Buyer(which can be accomplished by the mechanisms discussed above);

(4) disabling submission of offers and/or information related theretofrom the Invited Seller(s) to the Buyer (which can be accomplished bythe mechanisms discussed above);

5) disabling access to detailed information regarding the project by theInvited Seller(s) (which can be accomplished by the mechanisms discussedabove); and

(6) disabling exchange of information between the Buyer and the InvitedSeller(s) as desired (which can be accomplished by the mechanismsdiscussed above).

As described above, a likelihood index (LI) is calculated to derive thelikelihood (or probability) that an offer from an Identified Seller willbest match the Buyer's project (P). In the preferred embodiment of theinvention as depicted in FIG. 3, LI is derived from a weightedcalculation of a relevancy index and a priority index. For example, LIcan be calculated by multiplying respective factors or weights (e.g.,0.5, 0.5) to the relevancy index and the priority index, and thensumming the resultant values.

The relevancy index preferably is derived from a number of sub-indices,including a preferred-seller index, a geographical-proximity index, akeyword-matching index, and a relevant-samples-of-work index. Thepriority index preferably is derived from a number of sub-indices,including a quality-assurance index, a preferred-seller popularityindex, a proposal-history index, a seller-seniority index, asubscription-expiration index, and a pay-per-proposal submission index.

The Preferred-Seller Index assigns a score to the Identified Sellerbased on whether or not that Identified Seller is on the Buyer'spreferred talent list. This list may be created by the Buyer over timefor Sellers with whom it has worked and whose work product and/orservice has been satisfactory. This list is stored and accessed as partof the buyer data in the Database 21. This index might comprise 30% ofthe relevancy index.

The Geographic-Proximity index assigns a score to the Identified Sellerbased on the geographic proximity of the Identified Seller to the Buyer.The geographical location for the Identified Seller and the Buyer can bestored and accessed as part of the data in the Database 21. This indexmight comprise 10% of the relevancy index.

The Keyword-Matching index assigns a score to the Identified Sellerbased on matching key words in the profile of the Identified Seller tokey words pertaining to the project (P). The profile of the IdentifiedSeller is maintained as seller data in the Database 21. The keywordspertaining to the project can be input (or selected) by the Buyer and/orautomatically extracted from the requirements of the project (P) asmaintained in the Database 21. This index might comprise 30% of therelevancy index.

The Relevant-Samples-of Work index assigns a score to the IdentifiedSeller based on samples of offers, services, products, etc. that theIdentified Seller has added to his or her profile as maintained by theDatabase 21 and that is deemed relevant to the project (P). This indexmight comprise 30% of the relevancy index.

The Quality-Assurance index assigns a score to the Identified Sellerbased on a quality control process established by the marketplace torate Sellers. For example, if an Identified Seller (or the profile of anIdentified Seller) has not been approved by a quality control team in aspecific market, then the Identified Seller might be assigned a lowerscore for this index. This index might comprise 10% of the priorityindex.

The Preferred-Seller-Popularity index assigns a score to the IdentifiedSeller based on the number of Buyers in a given market that haveselected a specific Seller and placed that Seller on their respective“preferred seller list.” For example, the Preferred-Seller-Popularityindex might range from 1%-100%, with one percentage point being awardedfor each preferred seller list on which the Identified Seller has beenplaced. The preferred seller lists that contribute to this index can beconstrained to particular Buyers, such as Buyers in the relevantindustry or field that pertains to the project (P). This index mightcomprise 10% of the priority index.

The Proposal-History index assigns a score to the Identified Sellerbased on a grading, rating, or feedback system for the offers andproposals historically submitted, if any, by the Identified Seller. Thisinformation is maintained in the Database 21. This index might comprise40% of the priority index.

The Seller-Seniority Index assigns a score to the Identified Sellerbased on the Identified Seller's seniority in the system and/ormarketplace. This information is maintained in the Database 21. Thisindex might comprise 20% of the priority index.

The Pay-Per-Proposal-Submission index assigns a score to the IdentifiedSeller based on the amount of money the Identified Seller is willing topay for submission of an offer. This information is maintained in theDatabase 21. This index might comprise 20% of the priority index.

In the above described embodiment of the invention, the relevancy andpriority indices each comprise 50% of the LI. But numerous other indicesand sub indices with different values and weighted characteristics canbe developed and used with the present invention to accomplish thedesired results depending on a Buyer's particular business and goals,and the particular talents and characteristics of the sellers in a givenmarket. Other possible sub-indices include the similarity of aparticular Identified Seller to other Identified Sellers that have beenidentified for a project and/or for prior similar projects; the numberof requirements of the project that are met by the Identified Seller'sparticular profile; the number of offers that a seller has submittedduring a period of time compared to the average number of offerssubmitted by other sellers; an Identified Seller's quoted price comparedto the average of the quoted prices submitted by other sellers; theamount of money that a seller is willing to pay to the marketplace inorder to earn the right to submit offers; the tier level of a seller inthe marketplace; the historical expensiveness of a seller compared tothe project's budget; and the seller's experience level.

As discussed above, a likelihood index table (LIT) stores LIs for anumber of Identified Sellers. Each LI represents the likelihood that thecorresponding seller will best match a Buyer's need for desired goodsand/or services as dictated by the project (P). The likelihood index ofa given seller is based on relevancy and priority indices generated forthe given Identified Seller as described above in more detail. The LITis preferably sorted according to the rank of the likelihood indicescontained therein in order to efficiently identify the highest rankedIdentified Sellers. The rank of an Identified Seller in the LIT reflectsthe Identified Seller's probability of satisfying the Buyer's need forgoods and/or services relative to the other sellers in the LIT. Notethat the likelihood indices of the LIT can also account for the level ofactivity of Sellers in the marketplace (in order to first invite more orless active Sellers) and/or account for other factors that themarketplace may consider (in order to increase or decrease the level ofparticipation of individual Sellers).

After building the LIT, the system initiates a flow control process(FCP) to regulate the process and flow by which the Buyer receivesoffers from Identified Sellers. The FCP is intended to increase theBuyer's chances of finding the best Identified Seller for the project(P) at the beginning of the process. This is accomplished by allowingonly a small number of the highest ranked Identified Sellers in the LITto compete for the project early in the process. During this period oftime, the Buyer can evaluate the offers presented by these highestranked sellers without being bombarded with offers from other sellers.In short, the Identified Sellers most likely to get the project areallowed to compete for the project over a larger period of time withoutinterference from numerous other sellers. If the Buyer does not select aSeller early in the process, then a larger number of lower rankedIdentified Sellers are subsequently allowed to compete for the project(P).

The FCP operates over a number of processing cycles. In each processingcycle, the FCP calculates a number of Identified Sellers to classify as“invited.” An Invited Seller is an Identified Seller that has beenselected to submit one or more offers to the Buyer for the project (P).

Classification of an Identified Seller as “invited” can trigger thesystem to automatically perform various system tasks related to theproject (P), such as:

-   -   (1) notification to the Invited Seller that the Invited Seller        has been selected to submit one or more offers to the Buyer        (such notification can be carried out over the messaging        interface of Seller Application component 17 or by other        external messaging means such as telephone, fax, e-mail, SMS,        IM, etc); and    -   (2) notification to the Buyer of the Invited Seller (such        notification can be carried out over the messaging interface of        Buyer Application component 15 or by other external messaging        means such as telephone, fax, e-mail, SMS, IM, etc).        Classification of an Identified Seller as “invited” can also        trigger the system to enable actions and/or tasks to be        performed by the Invited Seller and/or the Buyer with regard to        the project (P), such as:    -   (1) communication between the Invited Seller and Buyer (such        communication can occur over a messaging interfaces of the        Seller and Buyer Application components 15, 17 or via external        messaging such as telephone, fax, e-mail, SMS, IM, etc);    -   (2) submission of an offer from the Invited Seller to the Buyer        (the offer can be stored in the Database 21 of the system and        accessed by and/or presented to the Buyer by the Buyer        Application component 15, or possibly communicated to the Buyer        via external messaging such as telephone, fax, e-mail, SMS, IM,        etc.);    -   (3) communication of information related to an offer from the        Invited Seller to the Buyer (the related information can be        uploaded to and stored on the Database 21 by the Seller        Application component 17 and accessed by and/or presented to the        Buyer by the Buyer Application component 15, or possibly        communicated to the Buyer via external messaging such as        telephone, fax, e-mail, SMS, IM, etc.);    -   (4) access to detailed information regarding the project (P) by        the Invited Seller (the detailed information can be uploaded to        and stored on the Database 21 by the Buyer Application component        15 and accessed by and/or presented to the Seller by the Seller        Application component 17, or possibly communicated to the        Invited Seller via external messaging such as telephone, fax,        e-mail, SMS, IM, etc.); and    -   (5) exchange of information between the Buyer and the Invited        Seller as required (such information exchange can be carried out        over the messaging interfaces of the Buyer Application component        15 and the Seller Application component 17, or possibly involve        external messaging such as telephone, fax, e-mail, SMS, IM,        etc.).

The number of new Invited Sellers for each process cycle can vary, andis preferably calculated based on a number of factors, including, butnot limited to, the deadline of the project, the total number ofIdentified Sellers, the number of offers (A) that the Buyer wants forthe project, the ratio of the total number of Invited Sellers overallversus the number of Invited Sellers that have actually submitted anoffer, etc. For each processing cycle, the new Invited Sellers have thehighest rank in the LIT for those Identified Sellers that have notalready been classified as Invited Sellers. In other words, during eachsubsequent processing cycle, the FCP identifies new lower-rankedIdentified Sellers as Invited Sellers.

At the end of each processing cycle, the FCP calculates the time periodfor the next processing cycle (if there is one) and continues to performthe processing for the next processing cycle. The calculation of theprocessing cycle times for the project is preferably based on a numberof factors, including, but not limited to, the deadline of the project,the time left on the project to receive offers, the number of IdentifiedSellers, the ratio of Invited Sellers versus Invited Sellers that havesubmitted an offer, etc.

The FCP can be implemented in various ways depending on the needs of abusiness. An exemplary embodiment of the FCP is illustrated in FIGS. 4Aand 4B, which begins in block 400 by defining a set of parametersutilized by the process as shown. In block 402, the process calculatesthe amount of time available to get offers (M). In the preferredembodiment, the calculation of M depends upon the needs of eachindividual business. For example, a business might want to receive 100%of all offers within the first 75% of the time period between the datethat the project posts and the deadline, which would give the business25% of the time before the deadline to do other things once it hasselected a seller. Block 402 also initializes KT and XT, which arevariables used to derive the processing cycle time over the cycles ofthe process. In the preferred embodiment, KT is a constant and XT isvariable that is initialized to KT and updated each processing cycle(block 442). Block 402 also preferably initializes the followingconstants: the maximum processing cycle time (MWT), the minimumprocessing cycle time (IWT), the maximum number of Identified Sellersthat can be classified as Invited Sellers in each processing cycle(MTT), and the minimum number of Identified Sellers that can beclassified as Invited Sellers in each processing cycle (ITT).

In block 404, the process calculates the initial number of InvitedSellers (INS), which is preferably based on the number of offers (A)that the Buyer wants for the project, and a predetermined constant KA(e.g., INS=A*KA). The constant KA is typically higher than 1.0, and isset based on an anticipated response rate, as well as the number ofcycles desired over the flow control process. Block 404 also initializesthe number of Identified Sellers to classify as Invited Sellers in thecurrent processing cycle (LNS) to INS (LNS=INS) and initializes thenumber of Identified Sellers in the LIT that have yet to be classifiedas Invited Sellers (TTN) as the number of Identified Sellers in the LIT.

The process then operates over a number of processing cycles (which aredefined by blocks 406, 410, 412, 418, 420). During each processingcycle, the process classifies a number of Identified Sellers as InvitedSellers (blocks 406 and 408) and waits for a processing cycle timeperiod. Classification of an Identified Seller as “invited” can triggerthe system to automatically perform various system tasks related to theproject as described above. Classification of an Identified Seller as“invited” can also trigger the system to enable actions and/or tasks tobe performed by the Invited Seller and/or the Buyer with regard to theproject as described above. The system can also monitor the number ofoffers the Buyer has received from Invited Sellers with respect to theproject. After each processing cycle, the process updates the variableTTN, calculates the number of Identified Sellers to classify as InvitedSellers in the next processing cycle, and calculates the wait time forthe next processing cycle (blocks 422 through 442) and then continues tothe next processing cycle or performs the last processing cycle (blocks444 to 447).

In block 406, the process selects the LNS highest ranked IdentifiedSellers from the LIT that are not already classified as “InvitedSellers.” During the first cycle, that group would simply consist of theLNS highest ranked Identified Sellers on the LIT. During the secondcycle, that group would consist of the next LNS highest rankedIdentified Sellers, etc.

In block 408, the process classifies the Identified Sellers selected inblock 406 as “Invited Sellers.”

In block 410, the process evaluates whether the amount of time (M) toget offers divided by variable (XT) is less than or greater than theminimum amount of time (IWT) for processing cycles. Variable (XT)increases each cycle by the preset multiple (KT), which makes the ratio(M/XT) approach zero for each subsequent processing cycle. If this ratiobecomes less than the minimum processing cycle time (IWT), the FCPcontinues to the path of blocks 444-447 to carry out the last processingcycle as described below. If this ratio is greater than the minimumprocessing cycle time (IWT), the FCP proceeds to block 412.

In block 412, if ((M/XT)>MWT), the FCP waits for the time periodspecified by constant MWT (block 418). If ((M/XT)<MWT), the FCP waitsfor the time period (M/XT) (block 420). These steps ensure that theprocessing cycle time does not exceed the designated maximum processingcycle time MWT. At the end of either block 418 or 420, the processproceeds to block 422.

In block 422, the process decreases the value of TTN by the value of LNS(e.g., TTN=TTN−LNS). TTN, which is the total number of IdentifiedSellers in the LIT that have yet to be classified as Invited Sellers,decreases each cycle as LNS new Identified Sellers are become invited.

In block 424, the process evaluates whether TTN is greater than zero. Ifthis condition is false (TTN=0), then there are no Identified Sellers inthe LIT that have not yet been classified as Invited Sellers, and theprocess continues to block 447 to terminate the invitation cycleprocessing. If the condition of block 412 is determined to be true(TTN>0), the FCP continues to block 426 and 428. In block 626, the FCPdetermines the total number of offers submitted from Invited Sellers(SA) and calculates the percentage of Invited Sellers that have yet tosubmit an offer (PAST). In block 428, the FCP calculates the number(NTS) of Identified Sellers to classify as Invited Sellers in the nextprocessing cycle, preferably based on a configurable constant (KN) andthe percentage of Invited Sellers that have yet to submit an offer(PAST) (e.g., NTS=(LNS)*(PAST)*(KN)).

In block 430, the FCP evaluates whether NTS (as calculated in block 428)is greater than the preset maximum number of Identified Sellers that canbe enabled during each processing cycle (MTT). If so, the FCP sets NTSequal to MTT (block 432) and proceeds to block 440. In block 434, theFCP evaluates whether NTS (as calculated in block 428) is less than thepreset minimum number of Identified Sellers that can be enabled duringeach processing cycle (ITT). If so, the FCP sets NTS equal to ITT (block436) and proceeds to block 440. The operations of blocks 430-436 ensurethat the number of Identified Sellers classified as Invited Sellers ineach processing cycle stays between a preset minimum and maximum numberand thus will not receive too few or too many offers during any givenprocessing cycle.

In block 438, the FCP evaluates whether the number of calculatedIdentified Sellers to classify as Invited Sellers in the next processingcycle (NTS) is greater than the number of Identified Sellers in the LITthat have yet to be classified as Invited Sellers (TTN).

If in block 438 (TS>TTN) is false, the FCP continues to blocks 440 and442. In block 440, the FCP sets LNS equal to NTS. In block 442, the FCPupdates variable XT, preferably based on a predetermined constant usedto derive processing cycle time (KT) (XT=XT*KT). The operations thenloop back to block 406 for the next processing cycle. Note that thechange to (XT) will cause the time period for the next cycle to change.Since the initial value of (XT) is (KT), the time period for eachsubsequent processing cycle changes by a factor of 1/(KT). The time ofeach processing cycle decreases as a function of M/(XT)ˆn where n=theprocessing cycle number. FIG. 4C depicts the number of Invited Sellersclassified over each one of a number of processing cycles as part of theflow control process described above for an exemplary project. The timefor the project extends along the X axis. The Y axis depicts the numberof Invited Sellers. The data lines correspond to the processing cyclesof the process. The relative position of a given data line along the Xaxis with respect to the previous data line indicates the duration ofthe corresponding processing cycle. The height of the data lineindicates the number of Invited Sellers classified during thecorresponding processing cycle.

If in block 438 (TS>TTN) is true, the FCP continues to the path ofblocks 444-447 to carry out the last processing cycle. In blocks 444,the FCP selects the remaining Identified Sellers in the LIT that haveyet to be classified as Invited Sellers. In block 445, the IdentifiedSellers selected in block 444 are classified as Invited Sellers. Inblock 446, the FCP process waits for a time M/XT. In block 447, theinvitation cycle processing stops and the FCP ends.

There have been described and illustrated herein several embodiments ofa system, methodology, and apparatus for matching sellers to a buyerover a network and for managing related information. While particularembodiments of the invention have been described, it is not intendedthat the invention be limited thereto, as it is intended that theinvention be as broad in scope as the art will allow and that thespecification be read likewise. Thus, while particular applicationserver architectures have been disclosed, it will be appreciated thatother architectures for web-based services can be used as well. Inaddition, while particular schema and data have been disclosed formatching voice over talent to buyers, it will be understood that thematching logic, systems and apparatus as described herein can be usedfor other applications, including, and not by way of limitation, systemsfor matching employers to potential employees, systems for matchingcorporate buyers to potential vendors and other suitable reverse auctionprocesses. Moreover, while particular methodologies have been disclosedin reference to the generation of the likelihood index table and flowcontrol process, it will be appreciated that other methodologies couldbe used as well. For example, the number of sellers classified as“Invited Sellers” in a given processing cycle of the flow controlprocess can be constant over the processing cycles (such as one percycle) and the time duration of the processing cycles can vary dependingon the percentage of Invited Sellers that have yet to submit an offer(PAST). It will therefore be appreciated by those skilled in the artthat yet other modifications could be made to the provided inventionwithout deviating from its spirit and scope as claimed.

1. A method for facilitating a transaction between a buyer and one of anumber of sellers, the transaction related to a project specified by thebuyer, the method comprising: identifying a set of sellers stored in adatabase; for each processing cycle over a number of processing cycles,selecting sellers from the set for classification as sellers of aparticular type; and automatically enabling at least one action carriedout by the sellers of the particular type.
 2. A method according toclaim 1, wherein: the duration of the processing cycles varies over theprocessing cycles.
 3. A method according to claim 2, wherein: theduration of the processing cycles are derived from a time periodspecified by the buyer.
 4. A method according to claim 3, wherein: thedurations of the processing cycles over time are derived from apredetermined constant that results in exponential reduction of saiddurations.
 5. A method according to claim 1, wherein: the number ofsellers selected for classification as sellers of a particular typevaries over the processing cycles.
 6. A method according to claim 5,wherein: the number of sellers selected for classification as sellers ofa particular type depends upon a number of offers that are submitted bysellers of the particular type and received by the buyer.
 7. A methodaccording to claim 5, wherein: the number of sellers selected forclassification as sellers of a particular type in an initial processingcycle depends on a number of offers the buyer wishes to receive asdictated by input from the buyer.
 8. A method according to claim 1,wherein: the number of sellers selected for classification as sellers ofa particular type is constant over the processing cycles.
 9. A methodaccording to claim 1, wherein: said at least one action includes thesellers of the particular type submitting offers and information relatedto the offers and storing the offers and related information in adatabase for access by the buyer.
 10. A method according to claim 9,wherein: the information related to the offers includes multimedia filesrelated to the offers.
 11. A method according to claim 1, wherein: saidat least one action includes the sellers of the particular typeaccessing detailed information related to the offer.
 12. A methodaccording to claim 1, wherein: said at least one action includescommunication between the sellers of the particular type and the buyer.13. A method according to claim 1, further comprising: automaticallynotifying the sellers of the particular type of their classification tothe particular type.
 14. A method according to claim 1, furthercomprising: automatically notifying the buyer of the sellers of theparticular type.
 15. A method according to claim 1, further comprising:calculating likelihood indices for the sellers of the set; and rankingthe sellers of the set according to the corresponding likelihoodindices.
 16. A method according to claim 15, wherein: the selection ofsellers from the set over said processing cycles is adapted to selecthigher ranked sellers before lower ranked sellers.
 17. A methodaccording to claim 16, wherein: the likelihood index for a seller isderived from a number of index calculations.
 18. A method according toclaim 17, wherein: said index calculations include a group of relevancysubindices and a group of priority subindices.
 19. A method according toclaim 18, wherein: said relevancy sub indices include at least one of: apreferred-seller index, a geographical-proximity index, akeyword-matching index, and a relevant-samples-of-work index; and saidpriority subindices include at least of: a quality-assurance index, apreferred-seller popularity index, a proposal-history index, aseller-seniority index, and a pay-per-proposal submission index.
 20. Amethod according to claim 1, wherein: the sellers of the set areidentified by an automated process that matches requirements of theproject as specified by the buyer to profile data of sellers.
 21. Amethod according to claim 20, wherein: the automated process performssimilarity analysis with respect to the requirements of the project andthe profile data of sellers.
 22. A system for facilitating a transactionbetween a buyer and one of a number of sellers, the transaction relatedto a project, the system comprising: means for interacting with a buyerover a communication network to specify a project and storing datarelated to the project in a database; means for interacting with anumber of sellers over the communication network and storing datarelated to the sellers in the database; logic that performs an automatedprocess for identifying a set of sellers stored in a database; logicthat operates of over a number of processing cycles, wherein in eachprocessing cycle, the logic selects sellers from the set forclassification as sellers of a particular type; and logic thatautomatically enables at least one action carried out by the sellers ofthe particular type.
 23. A system according to claim 22, wherein: theduration of the processing cycles varies over the processing cycles. 24.A system according to claim 23, wherein: the duration of the processingcycles are derived from a time period specified by the buyer.
 25. Asystem according to claim 24, wherein: the durations of the processingcycles over time are derived from a predetermined constant that resultsin exponential reduction of said durations.
 26. A system according toclaim 22, wherein: the number of sellers selected for classification assellers of a particular type varies over the processing cycles.
 27. Asystem according to claim 26, wherein: the number of sellers selectedfor classification as sellers of a particular type depends upon a numberof offers that are submitted by sellers of the particular type andreceived by the buyer.
 28. A system according to claim 26, furthercomprising: means for interacting with the buyer over the communicationnetwork to specify a number of offers that the buyer wished to receivefor the project, wherein the number of sellers selected forclassification as sellers of a particular type in an initial processingcycle depends on the number of offers the buyer wishes to receive asspecified by the buyer.
 29. A system according to claim 22, wherein: thenumber of sellers selected for classification as sellers of a particulartype is constant over the processing cycles.
 30. A system according toclaim 22, wherein: said at least one action is carried out by means forinteracting with sellers of the particular type over the communicationnetwork to submit offers and information related to the offers andstoring the offers and related information in the database for access bythe buyer.
 31. A system according to claim 30, wherein: the informationrelated to the offers includes multimedia files related to the offers.32. A system according to claim 22, wherein: said at least one action iscarried out by means for providing the sellers of the particular typeaccess to detailed information related to the offer.
 33. A systemaccording to claim 22, wherein: said at least one action is carried outby means for providing communication between the sellers of theparticular type and the buyer.
 34. A system according to claim 22,further comprising: means for automatically notifying the sellers of theparticular type of their classification to the particular type.
 35. Asystem according to claim 22, further comprising: means forautomatically notifying the buyer of the sellers of the particular type.36. A system according to claim 22, further comprising: logic forcalculating likelihood indices for the sellers of the set, and logic forranking the sellers of the set according to the corresponding likelihoodindices.
 37. A system according to claim 22, wherein: the selection ofsellers from the set over said processing cycles is adapted to selecthigher ranked sellers before lower ranked sellers.
 38. A systemaccording to claim 37, wherein: the likelihood index for a seller isderived from a number of index calculations.
 39. A system according toclaim 38, wherein: said index calculations include a group of relevancysubindices and a group of priority subindices.
 40. A system according toclaim 39, wherein: said relevancy sub indices include at least one of: apreferred-seller index, a geographical-proximity index, akeyword-matching index, and a relevant-samples-of-work index; and saidpriority subindices include at least of: a quality-assurance index, apreferred-seller popularity index, a proposal-history index, aseller-seniority index, and a pay-per-proposal submission index.
 41. Asystem according to claim 22, wherein: wherein the automated processmatches requirements of the project as specified by the buyer to profiledata of sellers.
 42. A system according to claim 41, wherein: theautomated process performs similarity analysis with respect to therequirements of the project and the profile data of sellers.
 43. Anapplication server, operably coupled to the Internet, for facilitating atransaction between a buyer and one of a number of sellers, thetransaction related to a project, the application server comprising: adatabase; means for interacting with a buyer computer system over acommunication network to specify a project and storing data related tothe project in the database; means for interacting with a number ofseller computer systems over the communication network and storing datarelated to the sellers in the database; logic that performs an automatedprocess for identifying a set of sellers stored in a database; logicthat operates of over a number of processing cycles, wherein in eachprocessing cycle, the logic selects sellers from the set forclassification as sellers of a particular type; and logic thatautomatically enables at least one action carried out by the sellers ofthe particular type.